feat: standardise SP approval review tracking with issue template#28
Conversation
Introduces a standard SP approval review issue template in tpm-utils and updates the approval runbook to use it as the source of truth. Removes duplicated field definitions from the runbook and ensures all SP approval reviews are tracked consistently with clear triggers, UTC timestamps, investigation windows, diagnosis, and outcomes. The template captures: - review trigger and timing - failing metrics and thresholds - investigation window and maintenance context - communication with SPs - diagnosis and classification of issues - decision, actions taken, and supporting evidence This improves operational consistency, auditability, and handover between approvers as we approach mainnet production readiness.
There was a problem hiding this comment.
Pull request overview
Adds a standardized GitHub issue template for Storage Provider (SP) approval reviews so operational tracking is consistent and auditable, and positions the template as the intended “source of truth” referenced by the runbook.
Changes:
- Introduces a new SP approval review issue template with structured sections for trigger, metrics, investigation window, communications, diagnosis, outcome, actions, and evidence.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
rjan90
left a comment
rjan90
left a comment
There was a problem hiding this comment.
Generally looks good to me
github-project-automation
Bot
moved this from 🔎 Awaiting review
to ✔️ Approved by reviewer
in FOC
|
Which process should the SP who is preparing to be approved go through? |
Good question @beck-8 👍 There isn’t a separate approval “application” flow - approval is based on observed behaviour. I’ve added a short SP approval entry point section to the runbook to make this explicit: SPs receive Dealbot traffic, consistently meet SLA thresholds, and are approved based on sustained performance. Let me know if you think we should formalise that further, but for now, this reflects how we’re operating. |
|
I hope there can be a process for this too, just a short record. The consent record can be viewed internally anywhere. Ah, I might have asked a little more clearly. Do we go through this process when approving new SPs? If so, I think the corresponding fields need to be optimized. |
|
@TippyFlitsUK Can you answer my questions above? |
|
Still on my list @beck-8 👍 |
|
@TippyFlitsUK what are the next steps here, before it can land? |
…reviews, and periodic checks Addresses @beck-8's feedback that the template should cover SP onboarding, not just breach reviews. Adds a Review Type selector at the top and marks breach-specific sections as conditional. Adds a Decision owner field to make ownership explicit in the issue body.
Added thresholds and metrics for data storage and retrieval.
|
Hey @BigLep. Can you click "merge" on this one? 🙏 |
@TippyFlitsUK : doing now |
|
Thanks, buddy! ❤️ |
Introduces a standard SP approval issue template in tpm-utils and updates the approval runbook to use it as the source of truth.
Standardises tracking across all SP approval decisions with clear triggers, UTC timestamps, ownership, and outcomes:
A
Review Typeselector at the top of the template scopes which sections apply. Breach-only sections (Investigation Window, Diagnosis) are marked explicitly. The Outcome and Actions Taken sections cover all three paths.Other changes:
This improves operational consistency, auditability, and handover between approvers as we approach mainnet GA.